Minutes, IBIS Quality Committee

28 nov 2006

11-12 AM EST (8-9 AM PST)
Phone: 1.877.384.0543 or 1.800.743.7560
Web access: http://meetingplace.cisco.com/join.asp?2100472

ROLL CALL
  Adam Tambone
  Barry Katz
  Benny Lazer
  Benjamin P Silva
* Bob Ross, Teraspeed Consulting Group
  Brian Arsenault
* David Banas, Xilinx
* Eckhard Lenski
  Eric Brock
  Gregory R Edlund
  Hazem Hegazy
  John Figueroa
  John Angulo
  Katja Koller
  Kevin Fisher
* Kim Helliwell, LSI Logic
  Lance Wang
  Lynne Green
* Mike LaBonte, Cisco
* Moshiul Haque, Micron Technology
  Peter LaFlamme
  Robert Haller
* Roy Leventhal, Leventhal Design & Communications
  Sherif Hammad
  Todd Westerhoff
  Tom Dagostino
  Kazuyoshi Shoji
  Sadahiro Nonoyama

Everyone in attendance marked by  *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Bob: IBIS planning on funding IBIS.

Next meeting will be one week away.

AR Review:

- none

Continued review of the IQ spec:

- Roy described edits he made up to 4.2.8
We looked at the edited IQ specification provided by Roy.
Roy added a "Purpose" section. He also felt that we needed a definition
of "correctness":

 "Correctness is defined as conforming to a designated version of the IBIS Spec"

Kim felt that conforming to the datasheet was part of correctness too.
There was debate over this, and whether conforming to simulation results
was part of correctness.

We agreed that IQ comments "should be" in the file, not "must be" as written.
In check 2.2 we should explain why the latest [IBIS Ver] should be used.

Regarding check 1.1.2, we discussed whether ibischk ERRORs can be exempted.
Bob point out that ibischk would print an ERROR when [Model Selector] and
[Receiver Thresholds] are used for diff pair, for example. This would be a
case where an otherwise correct IBIS file would be in ERROR according to
ibischk.

We had a similar discussion for ibischk WARNINGs, asking the question of
whether these should be flagged with an X in the IQ designator. WARNINGs
for non-monotonic I/V curves have become too common, and are now largely
overlooked. We do not want the same to happen to the "X" designator, because
the intention is to have users look into the comments in the IBIS file.
But "pin C can not exceed 20pF" can be a legitimate and notable exception,
for example. If the bulk of the WARNINGs are for non-monotonic I/V, that
should be solved by using combined-curve checking, which Parser Bug 94
would address.

Next meeting:

05 Dec 2006
11-12 AM EST (8-9 AM PST)
Web access: http://meetingplace.cisco.com/join.asp?2102026

Meeting ended at 12:09 PM Eastern Time.